其他
工商银行近20年实时大数据平台建设历程
一、工行实时大数据平台建设历程
二、工行实时大数据平台建设思路
在 Kafka 之后,是实时计算平台。实时计算平台除了实现对时效要求较高的计算处理场景之外,它还可以通过 Flink 结合 HUDI/IceBerg 等产品实现实时数据入湖。而且能将 Flink 的结果输出到 HBase\ES 等联机数据库中。将这部分数据以服务的形式暴露,即数据中台服务,从而提供给应用调用。
粉色链路的数据,最终回到数据分析师那里,是蓝色链路的衍生。各个应用产生的数据,通过 Flink 和 HUDI 的实时数据入湖,通过 Presto 或 CK 等分析型引擎,供数据分析师进行 BI 分析。通过这条链路,数据时效得以提升,让分析师访问到分钟级延时的热数据,更加实时、准确地做出运营决策。一般高时效的业务场景,都包含在这条技术链路的体系之内。
因此工行做了架构改造,通过 CDC 数据复制技术,将主机实时发生的数据复制到大数据平台,通过 Flink 进行实时 ETL,数据搬运过来之后,充分利用大数据平台海量的计算能力,大幅提升预查询效率。原来每天跑 10 轮,现在每天可以跑 30 轮,原来每轮 30 分钟,现在每轮只要 10 分钟,既提升了时效又节省了成本。
为了解决这个问题,工行基于 Flink 研发了业务一致性对账中心,将服务化接口调用过程中的调用日志,统一汇集到 Kafka。基于 Flink 会话窗口的特性,判断交易中各个环节的调用是否完整。如果发现不完整的情况,会触发业务上的补账 / 核对动作,及时消除对客户账务的影响。
近几年各个行业对数据安全的重视程度都越来越高,而大数据平台作为全集群数据的汇集地,对数据安全保障方面能力的建设就显得更加重要。大数据平台不但要存储很多数据,而且要提供的各式各样的数据访问方式。
因此工行设计了一套全生命周期用数监控审计,类似于 Ngnix 的 access.log,主要用于事后追溯审计。当用户将数据拖回到本地时,平台会对数据加上水印,当有些数据被非正常公开后,就可以知晓数据泄漏的来源,同时对身份证、手机号、卡号等敏感字段,在返回时动态脱敏,比如 11 号的手机号中间几位都会变成“********”。
动态控权是因为有些数据访问权限控制粒度较细,工行实现了一套 SQL 改写引擎,在运行时对 SQL 进行解析,根据用户与表权限的对照关系,对 SQL 加上控制条件及脱敏函数,避免数据被越权访问。敏感数据识别是基于专家规则或 ML 模型,自动识别海量数据中的敏感信息,并自动进行分类分级。同时,提醒管理员对敏感信息和分类分级结果进行核实确认。
在公有云实现存算分离的最重要的原因就是:资源的超分配。超分配就是,假设公有云上有 10 个租户,每个租户分别申请了一个 10 节点的集群,但由于这 10 个租户的资源使用都会存在错峰的情况,因此云平台只要准备 50 台设备就可以满足上述需求,并不需要实际准备 100 台设备,这就是超分配。
私有云的大数据平台,一般会按业务线来划分集群。每个集群可能是数百台设备的规模,并不会出现大量的小租户、小集群,但集群间确实会存在一定错峰的情况。
对于这种情况,工行更倾向于使用固定资源 + 弹性资源混合部署架构。如图所示,左边基于裸金属的固定资源池,用于满足日常的资源需求。右边基于容器的弹性资源池,用于满足特定事件发生时突增的需求。同时,这部分弹性资源池,可以在不同的集群之间,动态调配复用。
三、展望
而通过 HybridSource 可以将 Hive 和 Kafka 中的数据抽象成一张表,通过一个作业就可以统计出最近 7 天的值,在 Flink 内部自动实现类似于 union 的功能,大幅提升研发效率。
因此后续希望 Flink 通过具备动态扩缩容的自适应能力,配置 min 和 max,引擎可以自动根据数据量的负载在 min-max 之间,调整使用的资源量从而提高整个平台的资源利用率。
作者丨袁一
来源丨公众号:InfoQ(ID:infoqchina)
🧐分享、点赞、在看,给个3连击呗!👇